• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The appearance data of a target entity is collected as appearance data, where the target entity comprises a physical entity capable of accessing, as a member, a trusted protocol. Appearance data is recorded in a distributed database associated with the trust protocol as an identity of the target entity. A target transaction initiated by a member node device in the trust protocol is received, in which the target transaction comprises the appearance data of the target entity that is collected by the member node device and a service event that is related to the entity that is detected by the member node device. A smart contract that corresponds to the service event is invoked. Based on the identity indicated by the target entity's appearance data, a service logic determined in the smart contract is executed.
    公开号:BR112019011063A2
    申请号:R112019011063-1
    申请日:2019-03-26
    公开日:2020-10-06
    发明作者:Danqing Hu；Shaorong Zhang
    申请人:Alibaba Group Holding Limited；
    IPC主号:
    专利说明:

    [001] [001] One or more realizations of the present invention relate to the field of trust protocol technologies (blockchain) and, in particular, to a method and apparatus for performing service based on trust protocol, and an electronic device. BACKGROUND OF THE INVENTION
    [002] [002] A trusted protocol technology, also known as distributed accounting technology, is a new technology in which one or more computing devices participate jointly in "accounting" and together maintain a complete distributed database. Trusted protocol technology has characteristics of decentralization, openness and transparency, each computing device can participate in database registration and computing devices can quickly perform data synchronization.
    [003] [003] The present specification provides a service execution method based on a trust protocol, and the method includes: collecting appearance data from a target entity and recording, in a distributed database of a trust protocol, the data appearance as an identity of the target entity; receive a target transaction initiated by a member node device in the trust protocol, where the target transaction includes the target entity's appearance data that is collected by the member node device and a service event that is related to the target entity and which is detected by the member node device; and invoking a smart contract that corresponds to the service event and executing, based on the identity indicated by the target entity's appearance data, the service logic determined in the smart contract.
    [004] [004] Optionally, an optical medium to solidify the appearance data of the target entity is sprayed on an external surface of the target entity; and the collection of the appearance data of a target entity include: collecting, using a mounted optical sensor, the appearance data of the target entity which is solidified by a nano-optical film.
    [005] [005] Optionally, the optical medium is the nano-optical film.
    [006] [006] Optionally, recording, in a distributed database of a trust protocol, the appearance data as an identity of the target entity includes: storing the appearance data in the distributed database of the trust protocol to form an association with the identity of the target entity that is registered in the trust protocol.
    [007] [007] Optionally, the method also includes: when the appearance data collected from the target entity is changed, update, based on the changed appearance data, the appearance data that are registered in the distributed database of the trust protocol, generate a corresponding update record and store the update record in the distributed trust protocol database.
    [008] [008] Optionally, the target entity includes a vehicle and the member node device includes a public transport device that accesses the trust protocol.
    [009] [009] Optionally, the service event includes a vehicle violation event and the service logic determined in the smart contract includes violation processing logic that corresponds to the vehicle violation event.
    [010] [010] Optionally, the service event includes a vehicle accident event, and the service logic determined in the smart contract includes vehicle accident liability determination logic and vehicle accident settlement logic that correspond to the accident event vehicle.
    [011] [011] Optionally, the service event includes a traffic congestion event, and the service logic determined in the smart contract includes preferential right of way consent logic that corresponds to the traffic congestion event.
    [012] [012] Optionally, the service event includes a driving event of entering a section of road planned by a vehicle, and the service logic determined in the smart contract includes reward logic that corresponds to the driving event of entering a section of road planned by a vehicle.
    [013] [013] Optionally, the service event includes a driving event of entering a section of road planned by a vehicle, and the service logic determined in the smart contract includes service logic that corresponds to the driving event of entering a section of road planned by a vehicle.
    [014] [014] Optionally, the trust protocol is a consortium trust protocol.
    [015] [015] The present specification also provides a service execution device based on a trust protocol, and the device includes: a registration module, configured to collect appearance data from a target entity, and to register, in a database distributed from a trust protocol, the appearance data as an identity of the target entity; a receiving module, configured to receive a target transaction initiated by a member node device in the trust protocol, where the target transaction includes the appearance data of the target entity that is collected by the member node device and an event of service that is related to the target entity and that is detected by the member node device; and an execution module, configured to invoke a smart contract that corresponds to the service event and execute, based on the identity indicated by the target entity's appearance data, the service logic determined in the smart contract.
    [016] [016] Optionally, an optical medium to solidify the appearance data of the target entity is sprayed on an external surface of the target entity; and the registration module is configured to: collect, using a mounted optical sensor, the appearance data of the target entity which is solidified by the optical medium.
    [017] [017] Optionally, the optical medium is a nano-optical film.
    [018] [018] Optionally, the registration module is configured to: store the appearance data in the distributed database of the trust protocol to form an association with the identity of the target entity that is registered in the trust protocol.
    [019] [019] Optionally, the device also includes: an update module, configured for: when the appearance data collected from the target entity are changed, update, based on the changed appearance data, the appearance data that are registered in the database. distributed data from the trust protocol, generate a corresponding update record and store the update record in the distributed database of the trust protocol.
    [020] [020] Optionally, the target entity includes a vehicle and the member node device includes a public transport device that accesses the trust protocol.
    [021] [021] Optionally, the service event includes a vehicle violation event and the service logic determined in the smart contract includes violation processing logic that corresponds to the vehicle violation event.
    [022] [022] Optionally, the service event includes a vehicle accident event, and the service logic determined in the smart contract includes vehicle accident liability determination logic and vehicle accident settlement logic that correspond to the accident event vehicle.
    [023] [023] Optionally, the service event includes a traffic congestion event, and the service logic determined in the smart contract includes preferential right of way consent logic that corresponds to the traffic congestion event.
    [024] [024] Optionally, the service event includes a driving event of entering a section of road planned by a vehicle, and the service logic determined in the smart contract includes reward logic that corresponds to the driving event of entering a section of road planned by a vehicle.
    [025] [025] Optionally, the service event includes a driving event of entering a section of road planned by a vehicle, and the service logic determined in the smart contract includes service logic that corresponds to the driving event of entering a section of road planned by a vehicle.
    [026] [026] Optionally, the trust protocol is a consortium trust protocol.
    [027] [027] This specification also provides an electronic device, and the electronic device includes: a processor; and a memory, configured to store a machine executable instruction; where when reading and executing a machine executable instruction that is stored in memory and that corresponds to the service execution control logic based on a trust protocol, the processor is enabled to: collect appearance data from a target entity and record, in a database distributed from a trusted protocol, the appearance data as an identity of the target entity; receive a target transaction initiated by a member node device in the trust protocol, where the target transaction includes the target entity's appearance data that is collected by the member node device and a service event that is related to the target entity and which is detected by the member node device; and invoking a smart contract that corresponds to the service event and executing, based on the identity indicated by the target entity's appearance data, the service logic determined in the smart contract. BRIEF DESCRIPTION OF THE DRAWINGS
    [028] [028] Figure 1 is a flowchart that illustrates a service execution method based on a trust protocol, according to an accomplishment.
    [029] [029] Figure 2 is a schematic structural diagram illustrating an electronic device, according to one embodiment.
    [030] [030] Figure 3 is a block diagram illustrating a service execution device based on a trust protocol, according to an embodiment. DESCRIPTION OF REALIZATIONS OF THE INVENTION
    [031] [031] This specification provides a technical solution to record, in a trusted protocol, appearance data of a target entity in the real world as an identity of the target entity, and to trigger,
    [032] [032] During the realization, when a trust protocol operator needs to perform, in the trust protocol, a service related to the identity of the target entity, the trust protocol operator can predefine a service event related to the target entity, perform, in the trust protocol, a smart contract that corresponds to the service event and determine, in the smart contract, the service logic that corresponds to the service event and whose execution needs to be triggered based on the identity of the target entity.
    [033] [033] In addition, a node device in the trust protocol that is interconnected with the target entity can collect the appearance data of the target entity and record, in a distributed database of the trust protocol, the appearance data as the target entity's identity.
    [034] [034] In addition, after detecting the service event related to the target entity, a member node device (including the previous node device) in the trust protocol can create a target transaction and publish the target transaction in the trust protocol with based on the collected appearance data and the detected service event, initiate the smart contract contract call and then execute, based on the identity indicated by the target entity's appearance data, the service logic determined in the smart contract.
    [035] [035] On the one hand, as the target entity's appearance data is easy to collect, the target entity's appearance data is recorded in the distributed database of the trust protocol as the identity of the target entity, so that after detecting the service event corresponds to the target entity, the member node device in the trust protocol can quickly identify, in addition to collecting the appearance data of the target entity, the target entity that corresponds to the service event, to easily associate the service event with target entity's identity.
    [036] [036] On the other hand, as the appearance data of the target entity is recorded in the distributed database of the trust protocol as the identity of the target entity, when creating the transaction based on the appearance data of the target entity and the event of service and invoke the smart contract that is published in the trust protocol and which corresponds to the service event, the member node device in the trust protocol can execute, using the identity indicated by the target entity's appearance data, the service logic determined in the smart contract, to easily complete, in the trust protocol, the service interaction related to the identity of the target entity, thus improving the flexibility and extensibility of the trust protocol from a service perspective.
    [037] [037] In the following, this specification is described using specific achievements with reference to specific application scenarios.
    [038] [038] Figure 1 illustrates a service execution method based on a trust protocol, according to an accomplishment of this specification. The method is applied to any node device in a trusted protocol, to perform the following steps:
    [039] [039] Step (102): Collect appearance data from a target entity and record, in a distributed database of a trust protocol, the appearance data as an identity of the target entity.
    [040] [040] Step (104): Receive a target transaction initiated by a member node device in the trust protocol, where the target transaction includes the appearance data of the target entity that is collected by the member node device and an event of service that is related to the target entity and that is detected by the member node device.
    [041] [041] Step (106): Invoke a smart contract that corresponds to the service event and execute, based on the identity indicated by the target entity's appearance data, the service logic determined in the smart contract.
    [042] [042] The target entity can include any type of entity in the real world that can access the trust protocol as a member.
    [043] [043] For example, the target entity may include an entity such as a vehicle, a public transport device (for example, a traffic camera, traffic lights or a smart crosswalk), merchandise or the like. In real applications, these entities can be transformed into intelligent devices by placing a chip, sensor or other form of intelligent hardware within these entities and accessing the trust protocol as member devices.
    [044] [044] Correspondingly, the trust protocol described in this specification can include any type of trust protocol network that allows the target entity in the real world to access as a member.
    [045] [045] For example, in a scenario, the target entity can be a vehicle and the trust protocol can be a consortium trust protocol formed by member devices, such as an operator service, a service server, one or more vehicles and public transport devices, such as a traffic camera, traffic lights and a smart crosswalk. A consortium trust protocol operator can perform, based on the consortium trust protocol, an online service interaction related to a vehicle identity, such as a vehicle accident liability determination based on a trust protocol and vehicle accident settlement.
    [046] [046] The service event can include any type of online service that is related to the identity of the target entity and that needs to be implemented and performed by the operator of the trust protocol in the trust protocol.
    [047] [047] Correspondingly, the service logic determined in the smart contract that corresponds to the service event can include any form of the described service logic whose execution needs to be triggered based on the identity of the target entity.
    [048] [048] For example, in one scenario, the target entity is still a vehicle, the trust protocol is a consortium trust protocol formed by public transport devices that serve as member devices, for example, one or more vehicles, a traffic camera, traffic lights and a smart crosswalk, and the service event can include a “vehicle violation event”, a “vehicle accident event” or a “traffic congestion event” that is related to the vehicle that serves as a member device. In addition, the service logic that corresponds to the service events and that is determined in the smart contract can include “violation processing logic that corresponds to the vehicle violation event”, “vehicle accident determination logic and settlement logic vehicle accident that corresponds to the vehicle accident event ", and" logic of consent for preferential right of way that corresponds to the traffic congestion event ".
    [049] [049] The technical solutions of this specification are described in detail below using an example in which the target entity is a vehicle and the trust protocol is a consortium trust protocol.
    [050] [050] When the operator of the consortium trust protocol needs to implement, in the consortium trust protocol and based on a specific architecture of the consortium trust protocol, an online service
    [051] [051] For example, during the realization, the service event described by the operator can be used as a condition for executing the smart contract, and the smart contract can determine the program code (for example, some program methods or functions) which is related to the service logic and whose execution needs to be triggered when the condition of execution of the smart contract is satisfied.
    [052] [052] A specific type of service event described by the operator and the service logic that corresponds to the service event generally depends on an operator's actual service need. Achievements are not limited in this specification.
    [053] [053] For a developed smart contract, the operator can publish the smart contract in the consortium trust protocol using any node device in the consortium trust protocol, and the smart contract is recorded in the distributed database (ie, a distributed accounting) of the consortium trust protocol after some designated member node devices (for example, one or more authority node devices designated in the consortium trust protocol that have accounting privilege) in the consortium trust protocol reach consensus about the smart contract. Subsequently, a user can send a transaction to the smart contract registered in the trust protocol by accessing the client software from any node device, to initiate the smart contract contract call and trigger the execution of the related service logic in the trust protocol of consortium.
    [054] [054] It is worth noting that a consensus algorithm used when the member node device in the consortium trust protocol performs consensus processing in the smart contract published in the trust protocol and a specific consensus process is omitted in this report descriptive. A person skilled in the art can refer to records of related technologies when carrying out the technical solutions recorded in this specification.
    [055] [055] In this specification, the vehicle can be transformed into an intelligent transport device by inserting a chip, sensor or other form of intelligent hardware into the vehicle and accessing the trust protocol as a member device.
    [056] [056] In one embodiment shown, the generation hardware (for example, a USB key) of a private key and a public key can be inserted into the vehicle or a key algorithm used to generate a private key and a public key is added to a vehicle storage device. When accessing the consortium trust protocol as a member device, the vehicle can first create a pair of a private key and a public key using the assembled hardware of the private key and public key or by invoking the included key algorithm.
    [057] [057] Then, a transaction used to start the registration can be created later and, after the transaction is signed based on the generated private key, the transaction is published in the consortium trust protocol to request adherence to the consortium trust protocol . After receiving the transaction, some member node devices designated in the consortium trust protocol can verify a transaction signature based on a public key that matches the private key used when the transaction is signed and can perform consensus processing on the transaction after the signature verification is successful.
    [058] [058] When a consensus on the transaction is reached, the vehicle's public key can be calculated, and an account address is created for the vehicle in the consortium trust protocol. In this case, the vehicle successfully joins the consortium trust protocol as a member node device, and the account address generated for the vehicle is an identity of the member node device in the consortium trust protocol .
    [059] [059] In real applications, as the account address created by the consortium trust protocol for the vehicle after the vehicle joins the consortium trust protocol is usually the vehicle's identity in the consortium trust protocol, if the operator of the consortium trust protocol needs to perform, in the consortium trust protocol, the online deployment of some offline services whose execution needs to be triggered based on the real identity of the vehicle, the identity of the vehicle in the consortium trust protocol does not can be easily associated with the offline services deployed.
    [060] [060] For example, offline services are an online vehicle accident liability determination service and an online vehicle accident settlement service that must be completed in the consortium-based trust protocol. a vehicle tampering event detected. After a member node device in the consortium trust protocol detects that the vehicle commits a breach, as the member node device cannot know an actual identity of the violating vehicle in the consortium trust protocol, the node node device member cannot associate the detected vehicle violation event with the actual vehicle identity in the consortium trust protocol, and cannot complete the interaction of online services, such as determining vehicle accident liability and accident settlement vehicle, based on the smart contract published in the consortium trust protocol.
    [061] [061] In this specification, vehicle appearance data can be recorded in a distributed database of the consortium trust protocol as vehicle identity information in the consortium trust protocol.
    [062] [062] In a shown embodiment, such as a limb node device, the vehicle can collect vehicle appearance data using a built-in chip, a built-in sensor or other form of built-in smart hardware and then store the data from appearance collected in the distributed database of the consortium trust protocol to form an association with the vehicle account address in the consortium trust protocol, to record the vehicle appearance data as the vehicle identity information, in addition to the identity vehicle in the consortium trust protocol.
    [063] [063] Certainly, if the vehicle does not have an account address as an identity in the consortium trust protocol, the vehicle appearance data can be used directly as the vehicle identity in the consortium trust protocol. For example, vehicle appearance data serves as the vehicle's public key, and vehicle appearance data is calculated to create an account address for the vehicle as the identity in the trust protocol.
    [064] [064] In one embodiment shown, an optical medium for solidifying the vehicle's appearance data can be pre-sprayed onto an external surface of the vehicle.
    [065] [065] A specific material of the optical medium is not limited in this specification, and includes, but is not limited to any material that can be sprayed on the vehicle's outer surface to solidify the vehicle's appearance data.
    [066] [066] For example, in one embodiment, the optical medium can be a nano-optical film. The nano-optical film can be made of a nano-scale carbon structured material. After being sprayed onto the outer surface of the vehicle, the nanoscale carbon-structured material can wrap the entire vehicle to form a circuit, and the layer formed of nano-optical film can automatically solidify a shape of the vehicle.
    [067] [067] In addition, the vehicle can be mounted with an optical sensor configured to collect vehicle appearance data that is solidified by the nano-optical film, and optical detection is performed on the nano-optical film using the optical sensor, to collect the appearance data of the vehicle that is solidified by the nano-optical film.
    [068] [068] Certainly, in addition to the previously demonstrated achievement of solidifying and collecting vehicle appearance data by spraying the optical medium on the vehicle, in real applications, other methods can be used to collect vehicle appearance data, which are not listed one by one in this specification.
    [069] [069] For example, three-dimensional scanning can be performed across the vehicle to accurately collect vehicle appearance data; or a vehicle image is collected using visual technology, and vehicle appearance data is generated through calculation based on the collected image.
    [070] [070] In another embodiment shown, when the appearance data collected from the vehicle changes, for example, when a vehicle accident or other event that may change the shape of the vehicle occurs, the appearance data recorded in the protocol's distributed database Consortium trust data can be further updated based on the changed appearance data.
    [071] [071] In addition, during each update of the vehicle's appearance data that is recorded in the distributed database of the consortium trust protocol, a corresponding update record can be generated later. For example, a transaction that includes appearance data before the change and changed appearance data is generated and published in the distributed trust protocol database, and after consensus on the transaction is reached, the transaction is recorded in the distributed database of the consortium trust protocol.
    [072] [072] In this method, in some service scenarios in which historical changes to vehicle appearance data need to be invoked (for example, historical changes to vehicle appearance data are invoked to determine or assess vehicle damage), the data change of vehicle appearance data can be retrieved from the distributed database of the trust protocol.
    [073] [073] In this specification, after the vehicle appearance data is recorded in the distributed database of the consortium trust protocol as the vehicle identity, if any member node device in the consortium trust protocol detects an event vehicle-related service, the member node device can publish the service event detected in the consortium trust protocol in a transaction form and the member node devices in the consortium trust protocol that detect the service event perform consensus processing at the service event.
    [074] [074] In this specification, in the consortium trust protocol, consensus processing on the vehicle-related detected service event is a process in which node devices transmit the detected service event using the consortium trust protocol and make a joint decision on the service event based on “evidence” of the plurality of parties.
    [075] [075] For example, the service event is a vehicle violation event and the member node devices in the consortium trust protocol include, for example, one or more vehicles, a traffic camera, traffic lights and a lane. smart pedestrians. After a given traffic camera serving as a member node device in the consortium trust protocol detects that a particular vehicle has committed a violation, the traffic camera can transmit, in a transaction form, the detected vehicle violation event to the surrounding node devices in the consortium trust protocol and perform transaction consensus processing along with other surrounding member node devices that can also detect the vehicle tamper event, such as other vehicles, a traffic light and a lane pedestrian crossing. After a consensus is reached, it indicates that other node devices surrounding the traffic camera can also detect that the vehicle commits a violation, the vehicle violation event that is detected by the traffic camera is reliable and the plurality of parts determine together that the vehicle actually commits a violation.
    [076] [076] In this specification, after consensus is reached on the service event detected by the member node device, the member node device can still collect vehicle appearance data to determine the identity of the vehicle that corresponds to the event of service.
    [077] [077] For example, if the service event is a vehicle violation event, after detecting that the vehicle commits a violation, the member node device in the consortium trust protocol can still detect, using a mounted optical sensor, a nano-optical film sprayed on an external surface of the vehicle, to collect vehicle appearance data which is solidified by the nano-optical film, thus determining the identity of the vehicle currently in violation in the consortium trust protocol.
    [078] [078] In addition, the member node device in the consortium trust protocol can create a transaction based on the detected service event and the appearance data collected from the vehicle, to initiate the contract invocation of the smart contract that corresponds to the service event and that is implemented in the consortium trust protocol, and trigger, in the consortium trust protocol based on the real identity indicated by the vehicle appearance data, the execution of the service logic that corresponds to the service event and that is determined in the smart contract, thus completing the corresponding service interaction in the consortium trust protocol.
    [079] [079] For example, during the transaction, the created transaction can include a smart contract account address, and then the transaction can be sent to the smart contract as a smart contract entry based on the account address, to initiate the invocation of the smart contract and trigger the execution of the program code that is determined in the smart contract and that is related to the service logic corresponding to the service event.
    [080] [080] It is worth noting that when the member node device in the consortium trust protocol creates a transaction to initiate the invocation of the smart contract, the member node device can automatically create the transaction based on the service event detected and in the appearance data collected from the vehicle or the user can trigger the creation of the transaction.
    [081] [081] For example, if the user triggers the creation of the transaction to start invoking the smart contract, the vehicle can be assembled with voice interaction hardware and a driver can fire, initiating a voice instruction for the vehicle, creating automatic transaction in the vehicle, to initiate the invocation of the smart contract. If the service event is a traffic congestion event and the service logic determined in the smart contract is a preferential right of way consent logic that corresponds to the traffic congestion event, the voice instruction can be a voice instruction "Initiating a preferential right of way consent agreement".
    [082] [082] In addition, when the invocation of the smart contract is complete, the member node device may also transmit a warning message to one or more surrounding node devices. After receiving the warning message, the vehicle can play the warning message to the driver in a voice or other format. If the service event is a vehicle violation event and the service logic determined in the smart contract is violation processing logic that corresponds to the vehicle violation event, the warning message can be a warning message “Vehicle driver with license plate no. XX committed a violation, and the smart contract has already helped you pay the fine. ”
    [083] [083] The technical solutions described with reference to specific service scenarios are described in detail below.
    [084] [084] In one embodiment shown, the member node devices that form the consortium trust protocol may include a consortium trust protocol operator server, one or more third party service servers, one or more vehicles, a traffic camera, traffic lights, a smart crosswalk, etc.
    [085] [085] The service server can be a server deployed by the operator based on an actual service need or it can be a third party service server interconnected with the operator. If an online vehicle accident liability determination service and an online vehicle accident settlement service are completed in the consortium trust protocol, the service server can be a service department of a management department of outsourced traffic or an insurance company that is interconnected with the operator.
    [086] [086] In a service scenario, an online service whose execution needs to be triggered based on the actual identity of the vehicle and which is implemented in the consortium trust protocol by the operator of the consortium trust protocol can be a processing service of online breach that must be completed in the consortium trust protocol based on a detected vehicle breach event.
    [087] [087] In this scenario, the service event can be a "vehicle tamper event" related to the vehicle. Correspondingly, the service logic that corresponds to the service event and that is determined in the smart contract can be "violation processing logic that corresponds to the vehicle violation event".
    [088] [088] For example, the violation processing logic can be logical when taking punitive measures, such as a fine and a penalty point based on a specific type of violation of the vehicle.
    [089] [089] Suppose that the smart crosswalk serving as a limb node device detects that a vehicle commits an “illegal parking in the crosswalk” violation event. The smart crosswalk can transmit, in the consortium trust protocol, the violation event to the limb node devices surrounding the smart crosswalk, for example, other vehicles, the traffic camera and traffic lights, to perform the consensus processing.
    [090] [090] After a consensus is reached, the member node device can create a transaction based on the breach event and the appearance data collected from the vehicle, to initiate the invocation of the smart contract contract (such as a processing contract violation) that corresponds to the violation event and that is implemented in the consortium trust protocol, and execute, in the consortium trust protocol, the violation processing logic that corresponds to the violation event and that is determined in the smart contract, thus completing punitive operations, such as a fine and a penalty point at a stored account address associated with the vehicle's appearance data.
    [091] [091] Upon completion of the invocation of the smart contract, the smart crosswalk serving as a member node device can transmit a warning message “Vehicle driver with license plate no. XX committed a violation, and the smart contract has already helped you pay the fine ”for the surrounding node devices, and the warning message is played back to the user using the vehicle.
    [092] [092] In another service scenario, online services whose execution needs to be triggered based on the real identity of the vehicle and which are implemented in the consortium trust protocol by the operator of the consortium trust protocol can be a determining service online vehicle accident liability service and an online vehicle accident settlement service that must be completed in the consortium trust protocol based on a detected vehicle violation event.
    [093] [093] In this scenario, the service event may be a "vehicle accident event" related to the vehicle. Correspondingly, the service logic that corresponds to the service event and that is determined in the smart contract can be “vehicle accident liability determination logic and vehicle accident settlement logic that corresponds to the vehicle accident event” .
    [094] [094] For example, the vehicle accident liability determination logic and the vehicle accident settlement logic can be logic to determine the vehicle accident liability and the logic to perform the settlement.
    [095] [095] Suppose that the vehicle that serves as a limb node device detects that a “rear collision” accident occurs with the vehicle. The vehicle can transmit, in the consortium trust protocol, the vehicle accident event to the limb node devices surrounding the vehicle, for example, another vehicle, the intelligent crosswalk, the traffic camera and the traffic lights to perform consensus processing.
    [096] [096] After a consensus is reached, the member node device can create a transaction based on the vehicle accident event and the appearance data collected from the vehicle, to initiate the contract invocation of the smart contract (such as a contract vehicle accident liability determination) that corresponds to the vehicle accident event and which is implemented in the consortium trust protocol, and execute, in the consortium trust protocol, the vehicle accident liability determination logic and the vehicle accident settlement logic that correspond to the vehicle accident event and which are determined in the smart contract, thus completing an operation to determine the liability of the vehicle accident and an operation to perform the corresponding vehicle accident settlement.
    [097] [097] Upon completion of invoking the smart contract, the vehicle serving as a member knot device may reproduce a warning message “Full liability is confirmed and the insurance company has been informed of the payment of the settlement” to the driver .
    [098] [098] In another service scenario, an online service whose execution needs to be triggered based on the real identity of the vehicle and which is implemented in the consortium trust protocol by the operator of the consortium trust protocol can be a consent service preferential right of way online that must be completed in the consortium trust protocol based on a detected traffic congestion event.
    [099] [099] For example, after encountering vehicle congestion, a vehicle driver can actively grant the vehicle's preferential right of way to a surrounding vehicle, in order to obtain a passing priority.
    [0100] [0100] In this scenario, the service event can be a "traffic congestion event" related to the vehicle. Correspondingly, the service logic that corresponds to the service event and that is determined in the smart contract can be “logic of consent of preferential right of way that corresponds to the traffic congestion event”.
    [0101] [0101] In one example, the preferential right of way consent logic can be a processing logic that a vehicle automatically obtains X minutes of preferential right of way after the vehicle actively gives way to a vehicle that initiates entitlement consent preferential ticket. Alternatively, the preferential right of way consent logic can be a processing logic that a vehicle automatically obtains X minutes of preferential right of way after the vehicle actively gives way to a public transport vehicle (for example, a bus).
    [0102] [0102] In one embodiment, assume that the vehicle that serves as a limb node device detects that a congestion event happens to the vehicle. The vehicle can transmit, in the consortium trust protocol, the vehicle accident event to the limb node devices surrounding the vehicle, for example, another vehicle, the intelligent crosswalk, the traffic camera and the traffic lights to perform consensus processing.
    [0103] [0103] After a consensus is reached, the member node device can create a transaction based on the congestion event and the appearance data collected from the vehicle, to initiate the invocation of the smart contract (such as, for example, a contract preferential right of way consent) that corresponds to the vehicle accident event and which is implemented in the consortium trust protocol, and to execute, in the consortium trust protocol, the logic of preferential right of way consent that corresponds to the event vehicle accident and that is determined in the smart contract. After detecting which surrounding vehicles actively make their way, the member node device automatically grants a certain amount of preferential right of way time to vehicles that actively make their way, and transmits a warning message “X minutes of preferential right passages are obtained ”for these vehicles that actively lead the way.
    [0104] [0104] In another embodiment, the smart contract call shown above can also be triggered manually by a vehicle driver. After the driver encounters the congestion, the driver can perform voice interaction with the vehicle by sending a voice instruction “start the preferential right of way consent contract”, and the vehicle transmits a warning message “A next vehicle has an emerging ticket requirement and requests to use a right lane with an X minute contract reward of preferential right of way ”for other surrounding vehicles. After detecting which surrounding vehicles actively open the way, the vehicle automatically grants a certain amount of preferential right of way time to vehicles that actively give way, and transmits a warning message “X minutes of preferential right of way are obtained ”For these vehicles that actively lead the way.
    [0105] [0105] After the invocation of the smart contract is completed, the vehicle serving as a member knot device may reproduce a warning message “A driver who provided the path has already obtained X minutes of preferential right of way” for the driver.
    [0106] [0106] In another service scenario, an online service whose execution needs to be triggered based on the actual identity of the vehicle and which is implemented in the consortium trust protocol by the operator of the consortium trust protocol can be a rewards service online which must be completed in the consortium trust protocol based on a driving event detected from entering a section of road planned by a vehicle.
    [0107] [0107] The planned road section can be a preferred driving road section that is determined in a smart contract and that is planned by the consortium trust protocol operator or a third party (for example, a traffic management department) interconnected with the consortium trust protocol, for example, a congestion dispersion road section actively planned by the traffic management department in case of congestion.
    [0108] [0108] In this scenario, the service event can be the “driving event of entering a planned road section” that is related to the vehicle. Correspondingly, the service logic that corresponds to the service event and which is determined in the smart contract can be "reward logic that corresponds to the driving event of entering a section of road planned by a vehicle".
    [0109] [0109] For example, the reward logic can be a processing logic that a certain number of rewards are awarded to the driver after the vehicle actively enters the preferred driving road section. For example, a certain number of points or a certain duration of the preferential right of way can be automatically delivered to a driver's account as a reward.
    [0110] [0110] In one embodiment, assume that a traffic camera serving as a limb node device detects the driving event of entering a preferred driving section of a vehicle. The traffic camera can transmit, in the consortium trust protocol, the driving event to limb node devices surrounding the traffic camera, such as vehicles, the intelligent crosswalk and traffic lights, to perform consensus processing.
    [0111] [0111] After a consensus is reached, the traffic camera can create a transaction based on the driving event and the appearance data collected from the vehicle, to initiate the invocation of the smart contract contract (such as a contract traffic) that corresponds to the driving event and is implemented in the consortium trust protocol, and to execute, in the consortium trust protocol, the reward logic that corresponds to the driving event and which is determined in the smart contract. After detecting that vehicles are actively entering the planned road section, the traffic camera automatically awards a number of rewards to the drivers of those vehicles, and transmits a warning message “A XXX reward is obtained” to these vehicles.
    [0112] [0112] In another embodiment, the smart contract call shown above can also be triggered manually by a vehicle driver. When the driver encounters congestion and a final planned road section is transmitted in the consortium trust protocol, the driver can perform voice interaction with the vehicle by sending a voice instruction “start the traffic guide contract” and then actively drive to the planned road section to obtain the reward.
    [0113] [0113] In another service scenario, an online service whose execution needs to be triggered based on the real identity of the vehicle and which is implemented in the consortium trust protocol by the operator of the consortium trust protocol can be the service logic correspondent that must be completed in the consortium trust protocol based on a driving event detected from entering a section of road planned by a vehicle.
    [0114] [0114] In this scenario, the planned road section can be a restricted road section that is determined in a smart contract and that is planned by the consortium trust protocol operator or a third party (for example, a traffic management department ) interconnected with the consortium trust protocol, for example, a congested road section or a restricted road section.
    [0115] [0115] In this scenario, the service event can be the “driving event of entering a planned road section” that is related to the vehicle. Correspondingly, the service logic that corresponds to the service event and which is determined in the smart contract can be "service logic that corresponds to the driving event of entering a section of road planned by a vehicle".
    [0116] [0116] For example, the service logic can be a processing logic that the driver is charged a certain number of fees or a certain percentage of normal fees as additional fees in addition to the normal fees after the vehicle actively enters the road section restricted.
    [0117] [0117] In one embodiment, assume that a traffic camera that serves as a limb node device detects a driving event from entering a section of road restricted by a vehicle. The traffic camera can transmit, in the consortium trust protocol, the driving event to the limb node devices surrounding the traffic camera, such as vehicles, the intelligent crosswalk and traffic lights, to perform a consensus processing .
    [0118] [0118] After a consensus is reached, the traffic camera can create a transaction based on the driving event and the appearance data collected from the vehicle, to initiate the invocation of a smart contract contract (such as a contract traffic) that corresponds to the driving event and which is implemented in the consortium trust protocol, and to execute, in the consortium trust protocol, the service logic that corresponds to the driving event and which is determined in the smart contract. After detecting that vehicles are actively entering the restricted road section, the traffic camera automatically charges drivers of those vehicles a certain number of fees or a certain percentage of additional fees in addition to the normal fees, and transmits a warning message “You have entered on a restricted road section and XXX ”fees have already been charged for these vehicles.
    [0119] [0119] In previous achievements, examples in which the target entities are vehicles, are used to describe in detail the technical solutions of this specification. It is also worth noting that, in real applications, the target entities may be other types of entities that can access the trust protocol as members, which are not listed one by one in this specification.
    [0120] [0120] It can be seen in previous achievements that, on the one hand, as the appearance data of the target entity is easy to collect, the appearance data of the target entity is recorded in the distributed database of the trust protocol as the identity of the target entity, so that after detecting the service event that corresponds to the target entity, the member node device in the trust protocol can quickly identify, further collecting the appearance data of the target entity, the target entity that corresponds to the target event service, to easily associate the service event with the identity of the target entity.
    [0121] [0121] On the other hand, as the appearance data of the target entity is recorded in the distributed database of the trust protocol as the identity of the target entity, when creating the transaction based on the appearance data of the target entity and the event of service and invoke the smart contract that is published in the trust protocol and which corresponds to the service event, the member node device in the trust protocol can execute, using the identity indicated by the target entity's appearance data, the service logic determined in the smart contract, to easily complete, in the trust protocol, the service interaction related to the identity of the target entity, thus improving the flexibility and extensibility of the trust protocol from a service perspective.
    [0122] [0122] Corresponding to the previous method realizations, the present specification also provides a realization of a service execution apparatus based on a trust protocol. The realization of the service execution apparatus based on a trust protocol in the present specification can be applied to an electronic device. The realization of the device can be performed by software, hardware or a combination of hardware and software. Software realization is used as an example. As a logic device, the device is formed by reading a corresponding computer program instruction from a non-volatile memory to a memory by a processor of the electronic device including the device. In terms of hardware, Figure 2 is a structural diagram that illustrates the hardware of an electronic device including the service execution apparatus based on a reliable protocol, according to the present specification. In addition to a processor, a memory, a network interface and a non-volatile memory shown in Figure 2, the electronic device including the device in the realization can normally include yet other hardware based on an actual function of the electronic device. Details are omitted here for simplicity.
    [0123] [0123] Figure 3 is a block diagram that illustrates a service execution device based on a trust protocol shown in an example of the realization of this specification.
    [0124] [0124] Referring to Figure 3, a service execution device based on a trust protocol (30) can be applied to the electronic device shown in Figure 2, and includes a registration module (301), a receiving module ( 302) and an execution module (303).
    [0125] [0125] The registration module (301) is configured to collect appearance data from a target entity and register, in a distributed database of a trust protocol, the appearance data as an identity of the target entity.
    [0126] [0126] The receiving module (302) is configured to receive a target transaction initiated by a member node device in the trust protocol, where the target transaction includes the appearance data of the target entity that is collected by the node device and a service event that is related to the target entity and that is detected by the member node device.
    [0127] [0127] The execution module (303) is configured to invoke a smart contract that corresponds to the service event and execute, based on the identity indicated by the target entity's appearance data, the service logic determined in the smart contract.
    [0128] [0128] In the present embodiment, an optical means for solidifying the appearance data of the target entity is sprayed on an external surface of the target entity; and the registration module (301) is configured to: collect, using a mounted optical sensor, the appearance data of the target entity which is solidified by the optical medium.
    [0129] [0129] In the present embodiment, the optical medium is a nano-optical film.
    [0130] [0130] In the present embodiment, the registration module (301) is configured to: store the appearance data in the distributed database of the trust protocol to form an association with the identity of the target entity that is registered in the trust protocol.
    [0131] [0131] In the present embodiment, the service execution apparatus based on a trust protocol (30) also includes: an update module (304) (not shown in Figure 3), configured for: when the appearance data collected from the entity targets are changed, update, based on the changed appearance data, the appearance data that is recorded in the distributed protocol database of the trust, generate a corresponding update record and store the update record in the distributed protocol database reliable.
    [0132] [0132] In the present embodiment, the target entity includes a vehicle and the member node device includes a public transport device that accesses the trust protocol.
    [0133] [0133] In the present embodiment, the service event includes a vehicle violation event, and the service logic determined in the smart contract includes violation processing logic that corresponds to the vehicle violation event.
    [0134] [0134] In the present embodiment, the service event includes a vehicle accident event, and the service logic determined in the smart contract includes the vehicle accident liability determination logic and the corresponding vehicle accident settlement logic to the vehicle accident event.
    [0135] [0135] In the present embodiment, the service event includes a traffic congestion event and the service logic determined in the smart contract includes the preferential right of way consent logic that corresponds to the traffic congestion event.
    [0136] [0136] In the present embodiment, the service event includes a driving event of entering a section of road planned by a vehicle, and the service logic determined in the smart contract includes the reward logic that corresponds to the driving event of entering on a section of road planned by a vehicle.
    [0137] [0137] In the present embodiment, the service event includes a driving event of entering a section of road planned by a vehicle, and the service logic determined in the smart contract includes the service logic corresponding to the driving event of entering on a section of road planned by a vehicle.
    [0138] [0138] In the present embodiment, the trust protocol is a consortium trust protocol.
    [0139] [0139] For a process of realizing the functions and roles of each module in the device, references can be made to a process of carrying out a corresponding step in the previous method. Details are omitted here for simplicity.
    [0140] [0140] As a device realization basically corresponds to a method realization, for related parties, references can be made to related descriptions in the realization of the method. The embodiment of the apparatus described above is merely an example. The modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one position, or may be distributed over a plurality of network modules. Some or all of the modules can be selected based on actual needs to achieve the objectives of the solutions in this specification. A person skilled in the art can understand and realize the achievements of this specification without creative efforts.
    [0141] [0141] The system, device, module or unit illustrated in the previous achievements can be made using a computer chip or an entity, or can be made using a product having a specific function. A typical achievement device is a computer, and the computer can be a personal computer, a portable computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email sending and receiving device, a game console, a tablet computer, a usable device, or any combination of these devices.
    [0142] [0142] Corresponding to the described method realization, the present specification also provides an electronic device realization. The electronic device includes a processor and memory configured to store a machine-executable instruction, and the processor and memory are usually connected to each other using an internal bus. In another possible embodiment, the device may also include an external interface, to communicate with another device or component.
    [0143] [0143] In the present embodiment, when reading and executing a machine executable instruction that is stored in memory and that corresponds to the service execution control logic based on a reliable protocol, the processor is enabled to: collect appearance data from a target entity and record, in a distributed database of a trust protocol, the appearance data as an identity of the target entity; receive a target transaction initiated by a member node device in the trust protocol, where the target transaction includes the target entity's appearance data that is collected by the member node device and a service event that is related to the target entity and which is detected by the member node device; and invoking a smart contract that corresponds to the service event and executing, based on the identity indicated by the target entity's appearance data, the service logic determined in the smart contract.
    [0144] [0144] In the present embodiment, an optical medium for solidifying the appearance data of the target entity is sprayed on an external surface of the target entity; and when reading and executing a machine executable instruction that is stored in memory and that corresponds to the service execution control logic based on a reliable protocol, the processor is enabled to: collect, using a mounted optical sensor, the appearance data of the target entity that is solidified by the optical medium.
    [0145] [0145] In the present realization, when reading and executing a machine executable instruction that is stored in memory and that corresponds to the service execution control logic based on a trust protocol, the processor is able to: store the appearance data in the distributed database of the trust protocol to form an association with the identity of the target entity that is recorded in the trust protocol.
    [0146] [0146] In the present realization, when reading and executing a machine executable instruction that is stored in memory and that corresponds to the service execution control logic based on a reliable protocol, the processor is enabled for: when the collected appearance data of the target entity are changed, update, based on changed appearance data, the appearance data that are recorded in the distributed database of the trust protocol, generate a corresponding update record and store the update record in the distributed database of the trust protocol.
    [0147] [0147] A person skilled in the art can easily imagine another embodiment of the present invention after thinking about the present specification and practicing the present invention. The present specification is intended to cover any variations, uses or adaptations of the present invention, and those variations, uses or adaptations follow the general principles of this specification and include common knowledge or conventional techniques that are not disclosed in the existing technology of the present descriptive report. The specification and the achievements are merely considered as examples, and the actual scope and meaning of this specification are indicated by the following claims.
    [0148] [0148] It should be understood that the present specification is not limited to the precise structures that have been described above and shown in the drawings, and various modifications and changes can be made without departing from the scope of the present invention. The scope of the present invention is limited only by the appended claims.
    [0149] [0149] The descriptions described are merely examples of embodiments of the present invention, but are not intended to limit the present invention. Any modification, equivalent replacement or improvement made without departing from the meaning and principle of this specification will fall within the scope of protection of the present invention.
    权利要求:
    Claims (14)
    [1]
    1. METHOD FOR A SERVICE BASED ON A PROTOCOL OF TRUST, characterized by the method of understanding: collecting appearance data from a target entity, the target entity comprising a physical entity that can access a trust protocol as a member (102); register, in a distributed database of the trust protocol, the appearance data as an identity of the target entity (102); receive a target transaction initiated by a member node device in the trust protocol, where the target transaction comprises the appearance data of the target entity that is collected by the member node device and a service event that is related to the target entity and which is detected by the member node device (104); invoking a smart contract that corresponds to the service event (106); and perform, based on the identity indicated by the target entity's appearance data, a service logic determined in the smart contract (106).
    [2]
    2. METHOD, according to claim 1, characterized by an optical means for solidifying the appearance data of the target entity to be sprayed on an external surface of the target entity.
    [3]
    3. METHOD, according to claim 2, characterized by collecting the appearance data of the target entity comprising: collecting, using a mounted optical sensor, the appearance data of the target entity that is solidified by the optical medium.
    [4]
    METHOD according to claim 2, characterized in that the optical medium is a nano-optical film.
    [5]
    5. METHOD, according to any of the claims
    1 to 4, characterized by the fact that registering, in the distributed database of the trust protocol, the appearance data as the identity of the target entity (102) comprises: storing the appearance data in the distributed database of the trust protocol to form an association with the identity of the target entity that is registered in the trust protocol.
    [6]
    6. METHOD, according to any one of claims 1 to 5, characterized by further comprising: when the appearance data collected from the target entity are changed, update, based on the changed appearance data, the appearance data that are recorded in the distributed database of the trust protocol; generate a corresponding updated record; and store the updated record in the distributed database of the trust protocol.
    [7]
    7. METHOD according to any one of claims 1 to 6, characterized in that the target entity comprises a vehicle, and the member knot device comprises a public transport device that accesses the trust protocol.
    [8]
    8. METHOD, according to claim 7, characterized in that the service event comprises a vehicle violation event, and the service logic determined in the smart contract comprises violation processing logic that corresponds to the vehicle violation event.
    [9]
    9. METHOD, according to claim 7, characterized by the service event comprising a vehicle accident event, and the service logic determined in the smart contract comprising vehicle accident liability determination logic and vehicle accident settlement logic corresponding to the vehicle accident event.
    [10]
    10. METHOD, according to claim 7, characterized in that the service event comprises a traffic congestion event, and the service logic determined in the smart contract comprises the logic of preferential right of way consent that corresponds to the traffic congestion event traffic.
    [11]
    11. METHOD, according to claim 7, characterized by the service event comprising a driving event of entering a section of road planned by the vehicle, and the service logic determined in the smart contract comprising reward logic corresponding to the event of driving to enter a section of road planned by the vehicle.
    [12]
    12. METHOD according to claim 7, characterized by the service event comprising a driving event of entering a section of road planned by the vehicle, and the service logic determined in the smart contract comprising service logic corresponding to the event of driving to enter a section of road planned by the vehicle.
    [13]
    13. METHOD according to any one of claims 1 to 12, characterized in that the trust protocol is a consortium trust protocol.
    [14]
    14. DEVICE (30) FOR A SERVICE BASED ON RELIABLE PROTOCOL, characterized in that the device (30) comprises a plurality of modules (301, 302, 303) configured to execute the method, as defined in any one of claims 1 to 13.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112019011063A2|2020-10-06|method for a service based on trust protocol and apparatus for a service based on trust protocol
    US10783600B2|2020-09-22|Method and system using a blockchain database for data exchange between vehicles and entities
    EP3719758A1|2020-10-07|Parking charging method and apparatus, and electronic device
    Yan et al.2011|Crowdpark: A crowdsourcing-based parking reservation system for mobile phones
    CN107111937A|2017-08-29|The managed right to use system optimized for the magnitude of traffic flow
    EP3719759A1|2020-10-07|Method and device for free-flow tolling, and electronic device
    CN108966132A|2018-12-07|Navigation system based on block chain
    CN110427432A|2019-11-08|Violation event processing method, system, equipment and storage medium based on block chain
    TW202004683A|2020-01-16|Non-stop electronic toll collection method and apparatus, and electronic device
    CN109697473A|2019-04-30|A kind of detection method, computer installation and the computer readable storage medium of construction tunnel vehicle violation
    US20190370760A1|2019-12-05|Blockchain and cryptocurrency for real-time vehicle accident management
    CN106846819A|2017-06-13|A kind of taking photo by plane based on small aircraft and realizes system at penalty note generation method
    Campanile et al.2020|Privacy regulations, smart roads, blockchain, and liability insurance: putting technologies to work
    CN110490108A|2019-11-22|A kind of labeling method, device, storage medium and the electronic device of state violating the regulations
    CN111079196A|2020-04-28|Block chain-based radio frequency vehicle illegal recording management method, device and medium
    CN110046522A|2019-07-23|Method for processing business and device, electronic equipment based on block chain
    CN109243196A|2019-01-18|A kind of parking system and the method for realizing parking management
    Reddy2021|Blockchain-Enabled Decentralization Service for Automated Parking Systems
    AU2013251635B2|2017-04-13|System and method for generating permit reports
    CN112862984A|2021-05-28|Intelligent parking fee distribution method and block chain platform
    同族专利:
    公开号 | 公开日
    CN108520462A|2018-09-11|
    CN108520462B|2020-07-24|
    TWI696374B|2020-06-11|
    EP3571654A1|2019-11-27|
    WO2019191094A1|2019-10-03|
    PH12019501205A1|2020-01-20|
    AU2019203641A1|2019-10-17|
    JP6859511B2|2021-04-14|
    US20200175605A1|2020-06-04|
    AU2020270456A1|2020-12-17|
    US10719884B2|2020-07-21|
    KR102151366B1|2020-09-03|
    US11113769B2|2021-09-07|
    CA3044441A1|2019-09-30|
    TW201942830A|2019-11-01|
    KR20190114956A|2019-10-10|
    CN111861433A|2020-10-30|
    SG10202106085VA|2021-07-29|
    SG11201904942YA|2019-11-28|
    CA3044441C|2020-03-31|
    US20200160454A1|2020-05-21|
    US20190304027A1|2019-10-03|
    JP2020516968A|2020-06-11|
    US20210334906A1|2021-10-28|
    ZA201903423B|2021-06-30|
    MX2019006199A|2020-02-05|
    RU2728806C1|2020-07-31|
    US11049188B2|2021-06-29|
    EP3571654A4|2020-01-08|
    PH12019501205B1|2020-01-20|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    EP0980559A4|1997-05-09|2004-11-03|Gte Service Corp|Biometric certificates|
    US7703128B2|2003-02-13|2010-04-20|Microsoft Corporation|Digital identity management|
    US20070234058A1|2005-11-04|2007-10-04|White Charles A|System and method for authenticating products|
    US20090313129A1|2008-06-11|2009-12-17|Lmr Inventions, Llc|System and method for verifying user identity information in financial transactions|
    IT1399315B1|2010-04-08|2013-04-16|Cappelli|PROCEDURE FOR PLACING ON ANY PAINTABLE SURFACE, OF ELECTRIC LOAD CIRCUITS AND / OR GENERATORS AND CIRCUITS MADE WITH THIS PROCEDURE.|
    US20170220998A1|2012-06-14|2017-08-03|Gregory William Horn|Automated service management system with rule-based, cascading action requests|
    WO2015175722A1|2014-05-13|2015-11-19|Nant Holdings Ip, Llc|Healthcare transaction validation via blockchain proof-of-work, systems and methods|
    US10345767B2|2014-08-19|2019-07-09|Samsung Electronics Co., Ltd.|Apparatus and method for gamification of sensor data interpretation in smart home|
    US20160098730A1|2014-10-01|2016-04-07|The Filing Cabinet, LLC|System and Method for Block-Chain Verification of Goods|
    WO2017122187A2|2016-01-15|2017-07-20|Enrico Maim|Methods and systems implemented in a network architecture with nodes capable of performing message-based transactions|
    US20180108024A1|2016-06-03|2018-04-19|Chronicled, Inc|Open registry for provenance and tracking of goods in the supply chain|
    US10852396B2|2015-07-31|2020-12-01|Hewlett-Packard Development Company, L.P.|Turntable peripheral for 3D scanning|
    US10402792B2|2015-08-13|2019-09-03|The Toronto-Dominion Bank|Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers|
    CN106504353B|2015-09-07|2019-12-20|腾讯科技（深圳）有限公司|Vehicle charging method and device|
    EP3362970A4|2015-10-17|2019-06-26|Banqu, Inc.|Blockchain-based identity and transaction platform|
    US20170147808A1|2015-11-19|2017-05-25|International Business Machines Corporation|Tokens for multi-tenant transaction database identity, attribute and reputation management|
    EP3380984A4|2015-11-24|2019-07-31|Ben-Ari, Adi|A system and method for blockchain smart contract data privacy|
    US10521973B2|2015-12-17|2019-12-31|International Business Machines Corporation|System for monitoring and enforcement of an automated fee payment|
    US9849364B2|2016-02-02|2017-12-26|Bao Tran|Smart device|
    CA2931469A1|2016-03-27|2017-09-27|Sal Khan|Portable verifiable credentials and methods thereof|
    AU2017239933A1|2016-03-31|2018-11-08|Tbsx3 Pty Ltd|Information system for item verification|
    US10521775B2|2016-04-18|2019-12-31|R3 Ltd.|Secure processing of electronic transactions by a decentralized, distributed ledger system|
    US9610476B1|2016-05-02|2017-04-04|Bao Tran|Smart sport device|
    US10046228B2|2016-05-02|2018-08-14|Bao Tran|Smart device|
    EP3453005A1|2016-05-06|2019-03-13|Innogy Innovation GmbH|Traffic system|
    US10447478B2|2016-06-06|2019-10-15|Microsoft Technology Licensing, Llc|Cryptographic applications for a blockchain system|
    CA3031133A1|2016-07-18|2018-01-25|Royal Bank Of Canada|Distributed ledger platform for vehicle records|
    WO2018026807A1|2016-08-02|2018-02-08|Pcms Holdings, Inc.|Managing automotive vehicle premium lane access|
    JP6703918B2|2016-08-31|2020-06-03|ヤフー株式会社|Generation program, generation device, and generation method|
    US20180096175A1|2016-10-01|2018-04-05|James L. Schmeling|Blockchain Enabled Packaging|
    KR101849917B1|2016-10-13|2018-05-31|주식회사 코인플러그|Method for providing certificate service based on smart contract and server using the same|
    CN107045650B|2016-10-25|2021-06-11|罗轶|Network car booking system based on block chain|
    CN106529946A|2016-11-01|2017-03-22|北京金股链科技有限公司|Method for realizing user identity digitalization based on block chain|
    US10373159B2|2016-12-07|2019-08-06|International Business Machines Corporation|Concomitance of an asset and identity block of a blockchain|
    CN107135661A|2016-12-26|2017-09-05|深圳前海达闼云端智能科技有限公司|Data processing method, device, system and information collecting device|
    CN106845210A|2017-01-19|2017-06-13|布比（北京）网络技术有限公司|Event authentication method and apparatus|
    US20180218455A1|2017-01-30|2018-08-02|Dais Technology, Inc.|System for creating and utilizing smart policies on a blockchain|
    US9998286B1|2017-02-17|2018-06-12|Accenture Global Solutions Limited|Hardware blockchain consensus operating procedure enforcement|
    US20170173262A1|2017-03-01|2017-06-22|François Paul VELTZ|Medical systems, devices and methods|
    CN107341702B|2017-03-08|2020-06-23|创新先进技术有限公司|Service processing method and device|
    WO2018175666A1|2017-03-21|2018-09-27|Dappsters, LLC|Blockchain systems and methods|
    US20180285810A1|2017-03-29|2018-10-04|Ripe Technology, Inc.|Systems and methods of blockchain transaction recordation in a food supply chain|
    CN107341676A|2017-07-17|2017-11-10|深圳天净喔溯源科技有限公司|False proof mark and the method for tracing to the source|
    CN107516180A|2017-08-25|2017-12-26|迅鳐成都科技有限公司|A kind of system and method that storage transaction security and operating efficiency are improved based on block chain|
    TWM554608U|2017-09-01|2018-01-21|國泰人壽保險股份有限公司|Blockchain-based insurance service system|
    US11037095B2|2017-09-11|2021-06-15|Accenture Global Solutions Limited|Distributed ledger technology for freight system|
    CN107707633A|2017-09-19|2018-02-16|深圳市易成自动驾驶技术有限公司|Information of vehicles processing method, equipment and readable storage medium storing program for executing|
    CN207123875U|2017-09-20|2018-03-20|北京网录科技有限公司|A kind of drive recorder based on block chain technology|
    CN107682331B|2017-09-28|2020-05-12|复旦大学|Block chain-based Internet of things identity authentication method|
    US20190102850A1|2017-09-29|2019-04-04|David McMakin Wheeler|Smart city commodity exchange with smart contracts|
    CN107770159B|2017-09-30|2020-09-29|深圳市轱辘汽车维修技术有限公司|Vehicle accident data recording method and related device and readable storage medium|
    CN107835166A|2017-10-31|2018-03-23|济南浪潮高新科技投资发展有限公司|A kind of high value crystal retroactive method and device based on block chain|
    US10810683B2|2017-11-21|2020-10-20|General Electric Company|Hierarchical meta-ledger transaction recording|
    US10819684B2|2017-11-24|2020-10-27|International Business Machines Corporation|Cognitive blockchain for internet of things|
    US10686611B2|2017-11-24|2020-06-16|International Business Machines Corporation|Data anonymizing blockchain system|
    US11227457B2|2017-12-02|2022-01-18|International Business Machines Corporation|Blockchain managed storage|
    US20190172059A1|2017-12-05|2019-06-06|Bank Of America Corporation|Real-time net settlement by distributed ledger system|
    US11243945B2|2017-12-11|2022-02-08|International Business Machines Corporation|Distributed database having blockchain attributes|
    CN108009834B|2017-12-27|2021-10-15|上海唯链信息科技有限公司|Automobile insurance information system based on block chain technology|
    US20190207749A1|2018-01-04|2019-07-04|Sap Se|Validating shipment batches using distributed ledger systems|
    US20190207751A1|2018-01-04|2019-07-04|Bank Of America Corporation|Blockchain enterprise data management|
    US10659217B2|2018-01-05|2020-05-19|Bank Of America Corporation|Blockchain-based automated user matching|
    CN111861433A|2018-03-30|2020-10-30|创新先进技术有限公司|Service execution method and device based on block chain and electronic equipment|
    CN108876401B|2018-05-29|2022-03-01|创新先进技术有限公司|Commodity claim settlement method and device based on block chain and electronic equipment|KR102240120B1|2018-03-06|2021-04-13|아메리코프 인베스트먼트스 엘엘씨|Customized view of limited information recorded on the blockchain|
    US10951626B2|2018-03-06|2021-03-16|Americorp Investments Llc|Blockchain-based commercial inventory systems and methods|
    CN111861433A|2018-03-30|2020-10-30|创新先进技术有限公司|Service execution method and device based on block chain and electronic equipment|
    WO2019204094A1|2018-04-19|2019-10-24|Walmart Apollo, Llc|Systems and methods for decentralized content distribution|
    CN108876401B|2018-05-29|2022-03-01|创新先进技术有限公司|Commodity claim settlement method and device based on block chain and electronic equipment|
    CN109272385B|2018-09-14|2021-03-23|创新先进技术有限公司|Copyright event agent evidence storage method and system based on block chain|
    CN109274667B|2018-09-14|2020-06-23|阿里巴巴集团控股有限公司|Copyright event evidence storing method and system based on block chain|
    CN109327312B|2018-10-26|2020-03-24|阿里巴巴集团控股有限公司|Authentication method and device and electronic equipment|
    CN109542602B|2018-11-20|2021-05-11|苏州朗润创新知识产权运营有限公司|Block chain-based distributed task processing method, device and system|
    CN109947845A|2018-11-23|2019-06-28|阿里巴巴集团控股有限公司|A kind of block chain deposits card method, apparatus and computer equipment|
    CN110046522A|2018-11-28|2019-07-23|阿里巴巴集团控股有限公司|Method for processing business and device, electronic equipment based on block chain|
    CN109658704A|2018-11-29|2019-04-19|深圳市元征科技股份有限公司|A kind of overspeed of vehicle management method and system|
    CN110046193A|2018-11-30|2019-07-23|阿里巴巴集团控股有限公司|Data processing method, device and computer equipment based on block chain|
    CN110047008A|2018-12-18|2019-07-23|阿里巴巴集团控股有限公司|A kind of Claims Resolution method and apparatus based on block chain|
    CN109903163A|2019-03-05|2019-06-18|杭州秘猿科技有限公司|A kind of block bonusing method, device and the electronic equipment out of block chain|
    CN109816995B|2019-03-25|2020-05-29|江西理工大学|Intelligent traffic signal lamp safety dynamic regulation and control method based on alliance block chain technology|
    CN110400467A|2019-07-25|2019-11-01|深圳市元征科技股份有限公司|A kind of vehicle violation monitoring method, device and server|
    CN110659264A|2019-09-26|2020-01-07|联想有限公司|Business processing method and device for computing system and computing system|
    CN111857892B|2020-09-22|2020-12-18|支付宝信息技术有限公司|Method and device for processing service through block chain|
    法律状态:
    2021-01-19| B25A| Requested transfer of rights approved|Owner name: ADVANTAGEOUS NEW TECHNOLOGIES CO., LTD. (KY) |
    2021-02-09| B25A| Requested transfer of rights approved|Owner name: ADVANCED NEW TECHNOLOGIES CO., LTD. (KY) |
    2021-07-20| B07A| Application suspended after technical examination (opinion) [chapter 7.1 patent gazette]|
    2021-11-23| B09B| Patent application refused [chapter 9.2 patent gazette]|
    2021-11-23| B350| Update of information on the portal [chapter 15.35 patent gazette]|
    2022-02-08| B09B| Patent application refused [chapter 9.2 patent gazette]|Free format text: MANTIDO O INDEFERIMENTO UMA VEZ QUE NAO FOI APRESENTADO RECURSO DENTRO DO PRAZO LEGAL |
    优先权:
    申请号 | 申请日 | 专利标题
    CN201810277604.9A|CN108520462B|2018-03-30|2018-03-30|Service execution method and device based on block chain and electronic equipment|
    CN201810277604.9|2018-03-30|
    PCT/US2019/024070|WO2019191094A1|2018-03-30|2019-03-26|Blockchain-based service execution method and apparatus, and electronic device|
    [返回顶部]